Baremetal para IA local: por qué monté Ubuntu Server directo y no Proxmox con VMs

Baremetal para IA local: por qué monté Ubuntu Server directo y no Proxmox con VMs

por Raúl Unzué

¿Virtualización para IA?

Cuando empiezas a montar un laboratorio serio de IA local, hay una decisión que parece trivial, hasta que empiezas a mover modelos grandes. En mi caso, aún siendo especialista en virtualización, me surgieron dos dudas claras, ¿instalo un hipervisor tipo Proxmox y virtualizo todo, o dedico la máquina entera a Ubuntu Server baremetal?

Yo llevo años usando Proxmox. Me encanta. Para homelab, virtualización, servicios domésticos, Kubernetes, backups o segmentación de entornos, sigue siendo probablemente una de las mejores piezas de software que puedes tener en rack. Pero esta vez el objetivo era distinto, construir una máquina centrada al 100% en inferencia IA local, silenciosa, eficiente y optimizada para GPU.

Y ahí cambia completamente la película.

El servidor que estoy montando, el mismo sobre el que luego he publicaremos la guía de post-instalación de Ubuntu 24.04, no está pensado para correr veinte VMs pequeñas. Está diseñado para cargar modelos LLM continuamente, exprimir CUDA, minimizar latencias y evitar capas intermedias innecesarias entre la GPU y Ollama.

Por eso terminé descartando Proxmox como host principal y optando por Ubuntu Server directo sobre el hardware.

Hardware elegido para servidor de IA Local

Uno de los objetivos es disponer de un servidor silencioso que esté conectado 24x7, con bajo consumo, que me permita reutilizar algo de hardware de mi laboratorio y pueda mover IA local con cierta fluidez.

Dado que ya tenía memoria DDR5 tanto en un Nuc Extreme 13 como en un NAS Asustor, y que el precio actualmente es irracional, elegí re-utilizar 64GB para este proyecto. Hardware elegido:

  • Caja Fractal Design Terra:
    • Se trata de una caja compacta con muy buena construcción y distribución.
  • Placa base Minisforum BD895i SE:
    • Esta placa con AMD Ryzen 9 8945HX y NPU Ryzen AI (XDNA), que admite unos 96GB de RAM DDR5, dispone de un gran disipador para el procesador integrado y adaptadores para colocar un Noctua fácilmente. Buena calidad-precio.
  • Ventilador Noctua NF-A12x15 FLX de 4 pines para la CPU
  • 64GB DDR5 - 4800 mhz:
    • Disponía de ella, y da un rendimiento óptimo para lo que quiero. No es necesario subir a los 5200mhz que soporta la placa, porque la mejora es mínima y repercutiría en calor dentro de la caja.
  • GPU PNY RTX Pro 2000 Blackwell de 16GB VRAM:
    • Es el motor del laboratorio. Consumo energético eficiente y muy silenciosa. Lleva una GPU GB206 con 4.352 núcleos CUDA y 16 GB de memoria GDDR7 ECC.
    • Especificaciones de la NVIDIA RTX PRO 2000
      • Arquitectura: NVIDIA Blackwell
      • Núcleos CUDA: 4.352
      • Núcleos Tensor: 5ª generación
      • Núcleos de trazado de rayos (RT): 4ª generación
      • Potencia IA: 545 AI TOPS
      • Rendimiento en precisión simple (FP32): 17 TFLOPS
      • Rendimiento RT Cores: 52 TFLOPS
  • Disco duro 2TB Lexar NM790:
    • El controlador Maxio MAP1602 que usa, es famoso por ser extremadamente frío.
  • Fuente de alimentación CORSAIR SF750

Geeknetic Baremetal para IA local: por qué monté Ubuntu Server directo y no Proxmox con VMs 1

Dependencia de la GPU

En un entorno clásico de virtualización, Proxmox tiene muchísimo sentido:

  • Separas servicios
  • Haces snapshots
  • Migras máquinas
  • Aíslas entornos
  • Automatizas backups
  • Montas clusters

Pero los LLM locales no son una carga “normal”.

Aquí el cuello de botella ya no es CPU ni RAM, es la GPU y, sobre todo, cómo accede el software a ella.

Cuando empiezas a mover modelos de 7B, 14B o 22B cuantizados, cada GB de VRAM importa. Y cualquier capa adicional entre el host y CUDA empieza a notarse.

Sí, puedes hacer PCI passthrough de una NVIDIA en Proxmox. Funciona. Pero también introduces:

  • Complejidad extra
  • Problemas de drivers
  • Gestión de IOMMU
  • Posibles conflictos tras updates del kernel
  • Más consumo de RAM
  • Y, definitivamente, más puntos de fallo

Y sinceramente, no quería pasarme el tiempo debuggeando VFIO (Virtual Function I/O) cuando lo que quiero es lanzar modelos y experimentar.

Objetivo servidor IA

Este servidor no nace para consolidar infraestructura. Nace para esto:

Modelo Tamaño aprox. (Q4_K_M) Dónde corre Tokens/s aprox. Uso
Qwen2.5 0.5B / 1.5B ~0.5–1 GB 100% GPU 200–400 t/s Tests, agentes ligeros
Llama 3.2 3B ~2 GB 100% GPU 150–250 t/s Chatbot rápido, resúmenes
Mistral 7B / Qwen2.5 7B ~4.5 GB 100% GPU 80–120 t/s Sweet spot uso general
Llama 3.1 8B ~5 GB 100% GPU 70–110 t/s Razonamiento general
Gemma 3 12B ~7.5 GB 100% GPU 50–80 t/s Multimodal, contexto largo
Qwen2.5 14B ~9 GB 100% GPU 40–65 t/s Calidad alta
Mistral 22B ~13 GB 100% GPU (muy justo) 25–40 t/s Límite cómodo VRAM
Llama 3.3 70B ~40 GB GPU + RAM offload 5–15 t/s Posible, pero lento
Llama 3.1 405B ~230 GB No viable Fuera de alcance

Y cuando ves esa tabla, entiendes rápido dónde está la prioridad:

  • VRAM
  • Throughput
  • Latencia
  • Acceso directo a CUDA
  • Estabilidad 24/7
  • Y temperatura

No necesito hipervisores entre medias. Necesito que Ollama vea la GPU como si fuese suya. Porque lo es.

Menos capas en la Infraestructura de IA

Una de las cosas que más he aprendido montando infraestructura es que cada capa adicional añade fricción.

Con Proxmox habría terminado teniendo algo así:

Hardware → Proxmox → VM Ubuntu (añadiendo capa de Docker probablemente) → Ollama → CUDA → GPU

En baremetal, la cadena queda así:

Hardware → Ubuntu Server (capa Docker) → Ollama → CUDA → GPU

Mucho más limpia.

¿La diferencia parece pequeña? En IA local no lo es tanto.

Porque además del rendimiento puro, hay algo muy importante, la previsibilidad.

Cuando el servidor está dedicado exclusivamente a inferencia:

  • Las temperaturas son más consistentes
  • El consumo es más estable
  • Los ventiladores no pegan acelerones raros
  • CUDA no comparte recursos con otras VMs
  • Y la RAM no se fragmenta igual

Eso se nota especialmente cuando cargas modelos grandes continuamente o haces cargas parciales a RAM.

Uso de Docker

Y aquí viene el matiz importante, no he renunciado al aislamiento. Solo he cambiado el nivel donde ocurre.

En vez de virtualizar sistemas completos, estoy contenedorizando servicios concretos con Docker.

Porque para IA local, Docker tiene muchísimo más sentido:

  • Menos overhead
  • Acceso nativo a GPU
  • Despliegues rápidos
  • Stacks reproducibles
  • Integración perfecta con NVIDIA Container Toolkit
  • Y consumo muchísimo más eficiente

Es decir, sigo teniendo modularidad, pero sin penalizar el acceso al hardware.

Geeknetic Baremetal para IA local: por qué monté Ubuntu Server directo y no Proxmox con VMs 2

El factor silencio

Otro motivo importante de la decisión, es el ruido.

Cuando virtualizas mucho, normalmente acabas aumentando carga residual constante:

  • Más procesos
  • Más servicios
  • Más scheduling
  • Más consumo base
  • Más wakeups de CPU

Y en una máquina compacta con una RTX trabajando muchas horas, eso termina afectando a temperaturas y curvas de ventilación.

Mi objetivo aquí era casi absurdo, tener un servidor IA local potente, que pareciera apagado.

Por eso toda la optimización posterior tiene sentido:

  • Control total de los recursos del sistema
  • Gestión ventiladores
  • Persistencia NVIDIA
  • Límites de potencia
  • Optimización NVMe
  • Tuning térmico
  • Y Ubuntu Server minimalista

Geeknetic Baremetal para IA local: por qué monté Ubuntu Server directo y no Proxmox con VMs 3

¿No tiene sentido Proxmox en IA Local?

Esto no es un “Proxmox vs Ubuntu”. Son herramientas para objetivos distintos. De hecho, probablemente el siguiente nodo del laboratorio sí lleve Proxmox.

Pero esta máquina concreta no necesitaba ser un hipervisor. Necesitaba ser un appliance de inferencia IA local.

Algo estable, directo, silencioso y obsesionado con exprimir cada GB de VRAM.

Y para eso, baremetal sigue teniendo muchísimo sentido.

Fin del Artículo. ¡Cuéntanos algo en los Comentarios!

Temas Relacionados: IA Inteligencia Artificial IA Proxmox
Redactor del Artículo: Raúl Unzué

Raúl Unzué

Soy un apasionado de la virtualización con más de 20 años de experiencia, especializado en soluciones como VMware(premio vExpert y vExpert Pro desde 2013), Proxmox e Hyper-V. Durante mi carrera, he ayudado a empresas a optimizar sus infraestructuras TI mientras comparto mis conocimientos como redactor IT. Mi objetivo es traducir lo complejo en algo práctico y accesible, combinando teoría con experiencia real. Si te interesa la virtualización, las herramientas TI o simplemente aprender algo nuevo, espero ayudarte con mis artículos.